Service providers often attempt to balance the processing load associated with providing their services. One drawback with conventional load balancing is that the load balancing is typically performed across multiple layers and platforms. As a result, there are multiple levels of failure associated with the load balancing.
For example, in conventional network architectures, a client device may connect with a router to attempt to access a service. The router may interact with one or more domain name systems (DNSs) and global load balancing platforms to identify an Internet protocol (IP) address associated with the desired service. Once an IP address is identified, the router may forward the request to a local load balancing platform that will attempt to forward the request to an available server. Such an approach has many drawbacks. For example, the client may receive an initially valid IP address from a DNS resolver, but accessing the desired service may fail at any point in time thereafter. In such instances, the client will not know whether there is an alternate IP address for the service. Therefore, the client will try to connect to the IP address, wait a period of time and retry to establish a connection one or more times. During this period of time, the DNS entry in the client may expire based on a time-to-live (TTL) value and the DNS server will have to be queried again for a new valid IP address. Such processing consumes time and significant network resources.
Another problem with conventional network architectures is the inability to recover from problems that may occur during processing in an efficient manner. Still further, conventional load balancing architectures often do not permit processing to be performed across multiple load balancing platforms. For example, conventional architectures often require that a single server perform all the processing associated with a client session.